Contract First Development |
|
When creating Web services, there are two development styles: Contract-Last (also known as Code-First approach) and Contract-First. When using a contract-last approach, you start with the code, and let the Web service contract (WSDL) be generated from that. This is ideal for small applications and for learning Web services.
When using contract-first, you first create the WSDL contract or document , supporting schema and then use code to implement the said contract. For composite applications, long-lasting Web services and service-oriented architecture (SOA), contract-first way of development has advantages that usually outweigh the ease of method-first thinking. Of these two techniques, contract-first is the recommended way to create a Web service as in this approach the main focus is given to the messages that come in and go out from the Web service. This is also the correct approach to use in the SOA. A contract-first approach results in better long term development, interoperability and maintenance.
When you abstract code into services, contract-first makes it easier to use these services as pieces and plug them into where ever they might be needed. By first building the service's contract, it provides the structure to define and make those pieces work together. This allows you to consider a service as a stand alone piece of functionality. A service contract includes both functional and non-functional requirements. The functional requirements include what the service does, the service interface and the means of invocation. The non-functional requirements include service level agreement, security and quality of service, transactional constraints, process and semantic definitions.
Benefits of Contract First Development (CFD)
You need contract-first to give the service it's own scope of responsibility. A basic tenet of SOA is that a service is an autonomous unit of functionality. Also, it provides a definitive scope of what the service needs to provide.
- Increased visibility: A contract increases visibility and provides a neat package of functionality than can be used as a component in application infrastructure.
- Enables test-driven development: Because you get to know the functional requirements, you can develop test cases much before the code is even created, to determine if the services perform the required functionality within the constraints of the contract.
- Improved stability: Stability of the system is improved by versioning of contracts. Once a contract is established, it cannot be changed and it must be supported as long as consumers exist for it. However, new versions can be cloned and modified. By having both versions of the contract supported, new functionality can be built and made available to early adopters while the old contract is still supporting other applications. This allows a company to be agile in reacting to business changes while not breaking existing applications.